By default, your instance is enabled for basic monitoring. You can optionally enable detailed monitoring. After you enable detailed monitoring, the Amazon EC2 console displays monitoring graphs with a 1-minute period for the instance. The following table describes basic and detailed monitoring for instances.

1. Basic - Data is available automatically in 5-minute periods at no charge.
2. Detailed - Data is available in 1-minute periods for an additional cost. To get this level of data, you must specifically enable it for the instance. For the instances where you've enabled detailed monitoring, you can also get aggregated data across groups of similar instances.

References:

https://aws.amazon.com/cloudwatch/faqs/

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-cloudwatch-new.html

Check out this Amazon CloudWatch Cheat Sheet:

https://tutorialsdojo.com/aws-cheat-sheet-amazon-cloudwatch/

Amazon Elastic File System (Amazon EFS) provides simple, scalable, elastic file storage for use with AWS Cloud services and on-premises resources. When mounted on Amazon EC2 instances, an Amazon EFS file system provides a standard file system interface and file system access semantics, allowing you to seamlessly integrate Amazon EFS with your existing applications and tools. Multiple Amazon EC2 instances can access an Amazon EFS file system at the same time, allowing Amazon EFS to provide a common data source for workloads and applications running on more than one Amazon EC2 instance.

This particular scenario tests your understanding of EBS, EFS, and S3. In this scenario, there is a fleet of On-Demand EC2 instances that stores file documents from the users to one of the attached EBS Volumes. The system performance is quite slow because the architecture doesn't provide the EC2 instances a parallel shared access to the file documents.

Remember that an EBS Volume can be attached to one EC2 instance at a time, hence, no other EC2 instance can connect to that EBS Provisioned IOPS Volume. Take note as well that the type of storage needed here is a "file storage" which means that S3 (Option 1) is not the best service to use because it is mainly used for "object storage", and S3 does not provide the notion of "folders" too. This is why Option 2 is the correct answer.

Option 3 is incorrect because the scenario requires you to set up a scalable, high throughput storage system that will allow concurrent access from multiple EC2 instances. This is clearly not possible in EBS, even with Provisioned IOPS SSD Volumes. You have to use EFS instead.

Option 4 is incorrect because ElastiCache is an in-memory data store that improves the performance of your applications, which is not what you need since it is not a file storage.

Reference:

https://aws.amazon.com/efs/

Check out this Amazon EFS Cheat Sheet:

https://tutorialsdojo.com/aws-cheat-sheet-amazon-efs/

Check out this Amazon S3 vs EBS vs EFS Cheat Sheet:

https://tutorialsdojo.com/aws-cheat-sheet-amazon-s3-vs-ebs-vs-efs/

Here's a short video tutorial on Amazon EFS:

The correct answer is pilot light.

The term pilot light is often used to describe a DR scenario in which a minimal version of an environment is always running in the cloud. The idea of the pilot light is an analogy that comes from the gas heater. In a gas heater, a small flame that’s always on can quickly ignite the entire furnace to heat up a house. This scenario is similar to a backup-and-restore scenario.

For example, with AWS you can maintain a pilot light by configuring and running the most critical core elements of your system in AWS. When the time comes for recovery, you can rapidly provision a full-scale production environment around the critical core.

References:

https://media.amazonwebservices.com/AWS_Disaster_Recovery.pdf

Amazon EC2 has a soft limit of 20 instances per region, which can be easily resolved by completing the Amazon EC2 instance request form where your use case and your instance increase will be considered. Limit increases are tied to the region they were requested for.

Option 2 is incorrect as there is no such limit in the Availability Zone. 

Option 3 is incorrect. Network Access List is an optional layer of security for your VPC that acts as a firewall for controlling traffic in and out of one or more subnets. It does not affect the creation of new EC2 instances.

Option 4 is incorrect as there is no problem with your API credentials. 

References:

https://aws.amazon.com/ec2/faqs/#How_many_instances_can_I_run_in_Amazon_EC2

http://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html

Check out this Amazon EC2 Cheat Sheet:

https://tutorialsdojo.com/aws-cheat-sheet-amazon-elastic-compute-cloud-amazon-ec2/

AWS Step Functions provides serverless orchestration for modern applications. Orchestration centrally manages a workflow by breaking it into multiple steps, adding flow logic, and tracking the inputs and outputs between the steps. As your applications execute, Step Functions maintains application state, tracking exactly which workflow step your application is in, and stores an event log of data that is passed between application components. That means that if networks fail or components hang, your application can pick up right where it left off.

Application development is faster and more intuitive with Step Functions, because you can define and manage the workflow of your application independently from its business logic. Making changes to one does not affect the other. You can easily update and modify workflows in one place, without having to struggle with managing, monitoring and maintaining multiple point-to-point integrations. Step Functions frees your functions and containers from excess code, so your applications are faster to write, more resilient, and easier to maintain.

Option 1 is incorrect because SWF is a fully-managed state tracker and task coordinator service. It does not provide serverless orchestration to multiple AWS resources.

Option 2 is incorrect because although Lambda is used for serverless computing, it does not provide a direct way to coordinate multiple AWS services into serverless workflows.

Option 4 is incorrect because AWS Batch is primarily used to efficiently run hundreds of thousands of batch computing jobs in AWS.

Reference:

https://aws.amazon.com/step-functions/features/

In this scenario, you have two VPCs which have peering connections with each other. Note that a VPC peering connection does not support edge to edge routing. This means that if either VPC in a peering relationship has one of the following connections, you cannot extend the peering relationship to that connection:

For example, if VPC A and VPC B are peered, and VPC A has any of these connections, then instances in VPC B cannot use the connection to access resources on the other side of the connection. Similarly, resources on the other side of a connection cannot use the connection to access VPC B.

Hence, this means that you cannot use VPC-2 to extend the peering relationship that exists between VPC-1 and the on-premise network. For example, traffic from the corporate network can't directly access VPC-1 by using the VPN connection or the AWS Direct Connect connection to VPC-2, which is why Options 1, 3, and 4 are incorrect.

The correct answers are options 2 and 5. You can do the following to provide a highly available, fault-tolerant network connection:

• -Establish a hardware VPN over the Internet between the VPC and the on-premises network.
• -Establish another AWS Direct Connect connection and private virtual interface in the same AWS region. 

References:

https://docs.aws.amazon.com/vpc/latest/peering/invalid-peering-configurations.html#edge-to-edge-vgw

https://aws.amazon.com/premiumsupport/knowledge-center/configure-vpn-backup-dx/

https://aws.amazon.com/answers/networking/aws-multiple-data-center-ha-network-connectivity/

Check out this Amazon VPC Cheat Sheet:

https://tutorialsdojo.com/aws-cheat-sheet-amazon-vpc/

Amazon EBS encryption offers seamless encryption of EBS data volumes, boot volumes, and snapshots, eliminating the need to build and maintain a secure key management infrastructure. EBS encryption enables data at rest security by encrypting your data using Amazon-managed keys, or keys you create and manage using the AWS Key Management Service (KMS). The encryption occurs on the servers that host EC2 instances, providing encryption of data as it moves between EC2 instances and EBS storage. Hence, options 1 and 3 are the right answers.

Options 2 and 4 are incorrect as these relate only to S3.

Option 5 is incorrect as you only store keys in CloudHSM and not passwords.

Option 6 is incorrect as ACM only provides SSL certificates and not data encryption of EBS Volumes.

Reference:

https://aws.amazon.com/ebs/faqs/

Check out this Amazon EBS Cheat Sheet:

https://tutorialsdojo.com/aws-cheat-sheet-amazon-ebs/

Amazon DynamoDB Accelerator (DAX) is a fully managed, highly available, in-memory cache that can reduce Amazon DynamoDB response times from milliseconds to microseconds, even at millions of requests per second.

Option 1 is incorrect because the Amazon Elasticsearch service is a fully managed service that makes it easy for you to deploy, secure, operate, and scale your Elasticsearch engine to search, analyze, and visualize data in real-time. Although you may integrate Elasticsearch with DynamoDB, it will not reduce the DynamoDB response time from milliseconds to microseconds, even at millions of requests per second, whereas DynamoDB DAX can.

Option 2 is incorrect because AWS Device Farm is an app testing service that lets you test and interact with your Android, iOS, and web apps on many devices at once, or reproduce issues on a device in real time.

Option 3 is incorrect because DynamoDB Auto Scaling is primarily used to automate capacity management for your tables and global secondary indexes.

https://aws.amazon.com/dynamodb/dax

https://aws.amazon.com/device-farm

Check out this Amazon DynamoDB Cheat Sheet:

https://tutorialsdojo.com/aws-cheat-sheet-amazon-dynamodb/

Scaling based on a schedule allows you to scale your application in response to predictable load changes. For example, every week the traffic to your web application starts to increase on Wednesday, remains high on Thursday, and starts to decrease on Friday. You can plan your scaling activities based on the predictable traffic patterns of your web application.

To configure your Auto Scaling group to scale based on a schedule, you create a scheduled action. The scheduled action tells Amazon EC2 Auto Scaling to perform a scaling action at specified times. To create a scheduled scaling action, you specify the start time when the scaling action should take effect, and the new minimum, maximum, and desired sizes for the scaling action. At the specified time, Amazon EC2 Auto Scaling updates the group with the values for minimum, maximum, and desired size specified by the scaling action. You can create scheduled actions for scaling one time only or for scaling on a recurring schedule.

Option 3 is the correct answer. You need to configure a Scheduled scaling policy. This will ensure that the instances are already scaled up and ready before the start of the day since this is when the application is used the most.

Options 1 and 2 are incorrect because although this is a valid solution, it is still better to configure a Scheduled scaling policy as you already know the exact peak hours of your application. By the time either the CPU or Memory hits a peak, the application already has performance issues, so you need to ensure the scaling is done beforehand using a Scheduled scaling policy.

Option 4 is incorrect. Although the Application load balancer can also balance the traffic, it cannot increase the instances based on demand.

Reference:

https://docs.aws.amazon.com/autoscaling/ec2/userguide/schedule_time.html

Check out this AWS Auto Scaling Cheat Sheet:

https://tutorialsdojo.com/aws-cheat-sheet-aws-auto-scaling/

All of these happen when you stop a running EBS-backed EC2 instance except for option 4. The instance retains its associated Elastic IP addresses if it is in the EC2-VPC platform and not on EC2-Classic.

When you stop a running instance, the following happens:

Reference:

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Stop_Start.html

Check out this Amazon EC2 Cheat Sheet:

https://tutorialsdojo.com/aws-cheat-sheet-amazon-elastic-compute-cloud-amazon-ec2/

Always remember that the messages in the SQS queue will continue to exist even after the EC2 instance has processed it, until you delete that message. You have to ensure that you delete the message after processing to prevent the message from being received and processed again once the visibility timeout expires.

There are three main parts in a distributed messaging system:

1. The components of your distributed system (EC2 instances)

2. Your queue (distributed on Amazon SQS servers)

3. Messages in the queue.

You can set up a system which has several components that send messages to the queue and receive messages from the queue. The queue redundantly stores the messages across multiple Amazon SQS servers.

Refer to the third step of the SQS Message Lifecycle:

1. Component 1 sends Message A to a queue, and the message is distributed across the Amazon SQS servers redundantly.
2. When Component 2 is ready to process a message, it consumes messages from the queue, and Message A is returned. While Message A is being processed, it remains in the queue and isn't returned to subsequent receive requests for the duration of the visibility timeout. 
3. Component 2 deletes Message A from the queue to prevent the message from being received and processed again once the visibility timeout expires.

References:

https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-message-lifecycle.html

https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-basic-architecture.html

Check out this Amazon SQS Cheat Sheet:

https://tutorialsdojo.com/aws-cheat-sheet-amazon-sqs/

Throughput Optimized HDD (st1) volumes provide low-cost magnetic storage that defines performance in terms of throughput rather than IOPS. This volume type is a good fit for large, sequential workloads such as Amazon EMR, ETL, data warehouses, and log processing. Bootable st1 volumes are not supported.

Throughput Optimized HDD (st1) volumes, though similar to Cold HDD (sc1) volumes, are designed to support frequently accessed data.

Option 1 is incorrect because Amazon EBS Provisioned IOPS SSD is not the most cost-effective EBS type and is primarily used for critical business applications that require sustained IOPS performance.

Option 3 is incorrect because although an Amazon EBS General Purpose SSD volume balances price and performance for a wide variety of workloads, it is not suitable for frequently accessed, throughput-intensive workloads. Throughput Optimized HDD is a more suitable option to use than General Purpose SSD.

Option 4 is incorrect because although Amazon EBS Cold HDD provides the lowest cost HDD volume compared to General Purpose SSD, it is much suitable for less frequently accessed workloads.

Reference:

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html#EBSVolumeTypes_st1

Check out this Amazon EBS Cheat Sheet:

https://tutorialsdojo.com/aws-cheat-sheet-amazon-ebs/

An Elastic IP address is a static IPv4 address designed for dynamic cloud computing. An Elastic IP address is associated with your AWS account. With an Elastic IP address, you can mask the failure of an instance or software by rapidly remapping the address to another instance in your account.

An Elastic IP address is a public IPv4 address, which is reachable from the Internet. If your instance does not have a public IPv4 address, you can associate an Elastic IP address with your instance to enable communication with the Internet; for example, to connect to your instance from your local computer.

Option 1 is incorrect because it is already mentioned that your instances are in a public subnet. You only have to configure a NAT instance when your instances are on a private subnet.

Option 2 is the correct answer because you need to either add a public address or add an EIP for this EC2 instance for it to be able to access the internet.

Option 3 is incorrect because the public IP address has to be configured in the Elastic Network Interface (ENI) of the EC2 instance and not on its Operating System (OS).

Option 4 is incorrect because if the routing table was wrong then you would have an issue with the other 4 instances.

References: 

http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/elastic-ip-addresses-eip.html

AWS offers two kinds of NAT devices — a NAT gateway or a NAT instance. It is recommended to use NAT gateways, as they provide better availability and bandwidth over NAT instances. The NAT Gateway service is also a managed service that does not require your administration efforts. A NAT instance is launched from a NAT AMI.

Just like a NAT instance, you can use a network address translation (NAT) gateway to enable instances in a private subnet to connect to the internet or other AWS services, but prevent the internet from initiating a connection with those instances.

Here is a diagram showing the differences between NAT gateway and NAT instance:

Option 1 is incorrect because an Egress-only Internet gateway is primarily used for VPCs that use IPv6 to enable instances in a private subnet to connect to the Internet or other AWS services, but prevent the Internet from initiating a connection with those instances, just like what NAT Instance and NAT Gateway do. The scenario explicitly says that the EC2 instances are using IPv4 addresses which is why Egress-only Internet gateway is invalid, even though it can provide the required high availability.

Option 2 is incorrect because a VPC endpoint simply enables you to privately connect your VPC to supported AWS services and VPC endpoint services powered by PrivateLink without requiring an Internet gateway, NAT device, VPN connection, or AWS Direct Connect connection.

Option 4 is incorrect because although a NAT instance can also enable instances in a private subnet to connect to the Internet or other AWS services and prevent the Internet from initiating a connection with those instances, it is not as highly available compared to a NAT Gateway.

References:

https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-nat-gateway.html

https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-comparison.html

https://docs.aws.amazon.com/vpc/latest/userguide/egress-only-internet-gateway.html

Check out this Amazon VPC Cheat Sheet:

https://tutorialsdojo.com/aws-cheat-sheet-amazon-vpc/

In this scenario, it is best to use a combination of Cognito, Lambda, and S3. Cognito will handle the user authentication; Lambda provides the serverless architecture that allows you to run your code without deploying it in an EC2 instance and finally, S3 provides a scalable object storage.

AWS Lambda lets you run code without provisioning or managing servers. You pay only for the compute time you consume - there is no charge when your code is not running.

With Lambda, you can run code for virtually any type of application or backend service - all with zero administration. Just upload your code and Lambda takes care of everything required to run and scale your code with high availability. You can set up your code to automatically trigger from other AWS services or call it directly from any web or mobile app.

References:

https://aws.amazon.com/lambda/

https://aws.amazon.com/cognito/

https://aws.amazon.com/blogs/machine-learning/how-to-deploy-deep-learning-models-with-aws-lambda-and-tensorflow/

Amazon ElastiCache is a web service that makes it easy to deploy, operate, and scale an in-memory data store or cache in the cloud. The service improves the performance of web applications by allowing you to retrieve information from fast, managed, in-memory data stores, instead of relying entirely on slower disk-based databases.

Option 1 is incorrect because DynamoDB is primarily used as a NoSQL database which supports both document and key-value store models. ElastiCache is a more suitable service to use than DynamoDB, if you need an in-memory data store.

Option 2 is incorrect because RDS is mainly used as a relational database and not as a data storage for frequently used data.

Option 4 is incorrect because Redshift is a data warehouse service and is not suitable to be used as an in-memory data store.

References:

https://aws.amazon.com/elasticache/

https://aws.amazon.com/products/databases/

Check out this Amazon Elasticache Cheat Sheet:

https://tutorialsdojo.com/aws-cheat-sheet-amazon-elasticache/ 

In this scenario, the load balancer will route the incoming requests only to the healthy instances. When the load balancer determines that an instance is unhealthy, it stops routing requests to that instance. The load balancer resumes routing requests to the instance when it has been restored to a healthy state.

There are two ways of checking the status of your EC2 instances:

1. Via the Auto Scaling group

2. Via the ELB health checks

The default health checks for an Auto Scaling group are EC2 status checks only. If an instance fails these status checks, the Auto Scaling group considers the instance unhealthy and replaces. If you attached one or more load balancers or target groups to your Auto Scaling group, the group does not, by default, consider an instance unhealthy and replace it if it fails the load balancer health checks.

However, you can optionally configure the Auto Scaling group to use Elastic Load Balancing health checks. This ensures that the group can determine an instance's health based on additional tests provided by the load balancer. The load balancer periodically sends pings, attempts connections, or sends requests to test the EC2 instances. These tests are called health checks.

If you configure the Auto Scaling group to use Elastic Load Balancing health checks, it considers the instance unhealthy if it fails either the EC2 status checks or the load balancer health checks. If you attach multiple load balancers to an Auto Scaling group, all of them must report that the instance is healthy in order for it to consider the instance healthy. If one load balancer reports an instance as unhealthy, the Auto Scaling group replaces the instance, even if other load balancers report it as healthy.

References:

https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-healthchecks.html

https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-add-elb-healthcheck.html

Check out this AWS Elastic Load Balancing (ELB) Cheat Sheet:

https://tutorialsdojo.com/aws-cheat-sheet-aws-elastic-load-balancing-elb/

Here is an additional training material on why an Amazon EC2 Auto Scaling group terminates a healthy instance:

Amazon Glacier is an extremely low-cost storage service that provides secure, durable, and flexible storage for data backup and archival. Amazon Glacier is designed to store data that is infrequently accessed. Amazon Glacier enables customers to offload the administrative burdens of operating and scaling storage to AWS so that they don’t have to worry about capacity planning, hardware provisioning, data replication, hardware failure detection and repair, or time-consuming hardware migrations.

Option 1 is incorrect because storing cached session data is the main use case for ElastiCache and not Amazon Glacier.

Option 4 is incorrect because you should use RDS or DynamoDB for your active database storage as S3, in general, is used for storing your data or files.

Option 5 is incorrect because storing it for data warehousing is the main use case of Amazon Redshift. It does not meet the requirement of being able to archive your infrequently accessed data. You can use S3 standard instead for frequently accessed data or Glacier for infrequently accessed data and archiving.

It is advisable to transition the standard data to infrequent access first then transition it to Amazon Glacier. You can specify in the lifecycle rule the time it will sit in standard tier and infrequent access. You can also delete the objects after a certain amount of time.

In transitioning S3 standard to Glacier you need to tell S3 which objects are to be archived to the new Glacier storage option, and under what conditions. You do this by setting up a lifecycle rule using the following elements:

• -A prefix to specify which objects in the bucket are subject to the policy.
• -A relative or absolute time specifier and a time period for transitioning objects to Glacier. The time periods are interpreted with respect to the object’s creation date. They can be relative (migrate items that are older than a certain number of days) or absolute (migrate items on a specific date)
• -An object age at which the object will be deleted from S3. This is measured from the original PUT of the object into the service, and the clock is not reset by a transition to Glacier.

You can create a lifecycle rule in the AWS Management Console.

Reference:

https://aws.amazon.com/glacier/faqs/

Check out this Amazon Glacier Cheat Sheet:

https://tutorialsdojo.com/aws-cheat-sheet-amazon-glacier/

For this scenario, it is best to set up a self-monitoring EC2 instance with a virtual IP Address. You can use an Elastic IP and then write a custom script that checks the health of the EC2 instance and if the instance stops responding, the script will switch the Elastic IP address to a standby EC2 instance.

A custom script enables one Amazon Elastic Compute Cloud (EC2) instance to monitor another Amazon EC2 instance and take over a private "virtual" IP address on instance failure. When used with two instances, the script enables a High Availability scenario where instances monitor each other and take over a shared virtual IP address if the other instance fails. It could easily be modified to run on a third-party monitoring or witness server to perform the VIP swapping on behalf of the two monitored nodes.

Option 3 is incorrect because you don't have to postpone your deployment as you have the option to set up a self-monitoring EC2 instance with an EIP address.

Option 4 is incorrect as even though the Auto Scaling group provides high availability and scalability, it still depends on ELB which is not available in this scenario. Take note that you need to have a static IP address which can be in the form of an Elastic IP. Although an Auto Scaling group can scale out if one of the EC2 instances became unhealthy, you still cannot directly assign an EIP to an Auto Scaling group. In addition, you are only limited to use EC2 instance status checks for your Auto Scaling group if you do not have an ELB which can provide you the actual health check of your application (using its port), and not just the health of the EC2 instance.

Option 5 is incorrect because although this option is feasible, the goal of the company is to move the application to the cloud and not to continue using its on-premise resources. 

References:

https://aws.amazon.com/articles/leveraging-multiple-ip-addresses-for-virtual-ip-address-fail-over-in-6-simple-steps

https://aws.amazon.com/blogs/apn/amazon-vpc-for-on-premises-network-engineers-part-two/

https://aws.amazon.com/kinesis/data-firehose/

Check out this Amazon Kinesis Cheat Sheet:

https://tutorialsdojo.com/aws-cheat-sheet-amazon-kinesis/

When you create or update Lambda functions that use environment variables, AWS Lambda encrypts them using the AWS Key Management Service. When your Lambda function is invoked, those values are decrypted and made available to the Lambda code.

The first time you create or update Lambda functions that use environment variables in a region, a default service key is created for you automatically within AWS KMS. This key is used to encrypt environment variables. However, if you wish to use encryption helpers and use KMS to encrypt environment variables after your Lambda function is created, you must create your own AWS KMS key and choose it instead of the default key. The default key will give errors when chosen. Creating your own key gives you more flexibility, including the ability to create, rotate, disable, and define access controls, and to audit the encryption keys used to protect your data.

Reference:

https://docs.aws.amazon.com/lambda/latest/dg/env_variables.html#env_encrypt

Check out this AWS Lambda Cheat Sheet:

https://tutorialsdojo.com/aws-cheat-sheet-aws-lambda/

To calculate the total number of IP addresses of a given CIDR Block, you simply need to follow the 2 easy steps below. Let's say you have a CIDR block /27: 

1. Subtract 32 with the mask number : 

(32 - 27) = 5

2. Raise the number 2 to the power of the answer in Step #1 : 

2^ 5 = (2 * 2 * 2 * 2 * 2)

  = 32

The answer to Step #2 is the total number of IP addresses available in the given CIDR netmask. Don't forget that in AWS, the first 4 IP addresses and the last IP address in each subnet CIDR block are not available for you to use, and cannot be assigned to an instance. In addition, you can always associate a netmask of /27 which also has the same number of usable IP addresses (27) to help you with your exam.

Option 1 is the correct answer because the CIDR block of 172.0.0.0/27, with a netmask of /27, has an equivalent of 27 usable IP addresses. Take note that a netmask of /27 originally provides you with 32 IP addresses but in AWS, there are 5 IP addresses that are reserved which you cannot use. The first 4 IP addresses and the last IP address in each subnet CIDR block are not available in your VPC which means that you have to always subtract 5 IP addresses, hence 32 - 5 = 27. 

Option 2 is incorrect as a netmask of /28 only supports 16 IP Addresses.

Options 3 and 4 are incorrect as the only allowed block size is between a /28 netmask and /16 netmask. 

To add a CIDR block to your VPC, the following rules apply:

Reference:

http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Subnets.html

Check out this Amazon VPC Cheat Sheet:

https://tutorialsdojo.com/aws-cheat-sheet-amazon-vpc/

Amazon EMR is a managed cluster platform that simplifies running big data frameworks, such as Apache Hadoop and Apache Spark, on AWS to process and analyze vast amounts of data. By using these frameworks and related open-source projects such as Apache Hive and Apache Pig, you can process data for analytics purposes and business intelligence workloads. Additionally, you can use Amazon EMR to transform and move large amounts of data into and out of other AWS data stores and databases such as Amazon Simple Storage Service (Amazon S3) and Amazon DynamoDB.

Option 2 is wrong as Amazon Glacier is used for data archive only.

Option 3 is wrong as an EC2 instance is not a recommended storage service. In addition, Amazon EC2 does not have a built-in data processing engine to process large amounts of data.

Option 4 is wrong as Amazon RedShift is mainly used as a data warehouse service.

Reference:

http://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-what-is-emr.html

Check out this Amazon EMR Cheat Sheet:

https://tutorialsdojo.com/aws-cheat-sheet-amazon-emr/

Here is an in-depth tutorial on Amazon EMR:

You can connect and manage the EC2 instance so Option 2 is correct. You can install new packages and perform changes on the underlying infrastructure of the EC2 instance such as Enhanced Networking, Encryption, and so forth.

Elastic Beanstalk is a service that allows you to quickly deploy and manage your application in AWS. What it does is to automatically create EC2 instances for your application, which you can also manage just like a regular instance. Hence, Option 1 is correct.

Reference:

https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/Welcome.html

Check out this AWS Elastic Beanstalk Cheat Sheet:

https://tutorialsdojo.com/aws-cheat-sheet-aws-elastic-beanstalk/

AWS OpsWorks is a configuration management service that provides managed instances of Chef and Puppet. Chef and Puppet are automation platforms that allow you to use code to automate the configurations of your servers. OpsWorks lets you use Chef and Puppet to automate how servers are configured, deployed, and managed across your Amazon EC2 instances or on-premises compute environments. OpsWorks has three offerings - AWS Opsworks for Chef Automate, AWS OpsWorks for Puppet Enterprise, and AWS OpsWorks Stacks.

References: 

https://aws.amazon.com/opsworks/

The reason for this issue is that IAM users are created with no permissions by default. That means that when you created the new IAM user, you might not provisioned any permissions to the user. Hence, option 3 is correct and conversely, options 1 and 2 are wrong.

Option 4 is incorrect because provisions are applied immediately, and not after 24 hours.

The IAM user might need to make API calls or use the AWS CLI or the Tools for Windows PowerShell. In that case, create an access key (an access key ID and a secret access key) for that user. This is called Programmatic access.

If the user needs to access AWS resources from the AWS Management Console, create a password and provide it to the user.

References:

https://aws.amazon.com/iam/details/manage-users/

Here are the prerequisites for routing traffic to a website that is hosted in an Amazon S3 Bucket:

• -An S3 bucket that is configured to host a static website. The bucket must have the same name as your domain or subdomain. For example, if you want to use the subdomain acme.example.com, the name of the bucket must be acme.example.com.
• -A registered domain name. You can use Route 53 as your domain registrar, or you can use a different registrar.
• -Route 53 as the DNS service for the domain. If you register your domain name by using Route 53, we automatically configure Route 53 as the DNS service for the domain.

Reference:

https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/RoutingToS3Bucket.html

Check out this Amazon Route 53 Cheat Sheet:

https://tutorialsdojo.com/aws-cheat-sheet-amazon-route-53/

In this scenario, the EC2 instances you are currently using depends on a pre-built AMI. This AMI is not accessible to another region hence,  you have to copy it to the us-west-2 region to properly establish your disaster recovery instance.

You can copy an Amazon Machine Image (AMI) within or across an AWS region using the AWS Management Console, the AWS command line tools or SDKs, or the Amazon EC2 API, all of which support the CopyImage action. You can copy both Amazon EBS-backed AMIs and instance store-backed AMIs. You can copy encrypted AMIs and AMIs with encrypted snapshots.

Options 1 and 3 are incorrect because the AMI does not have a Network Access Control nor a Share functionality.

Option 4 is incorrect as you can use a unique or pre-built AMI to a specific region only.

References: 

http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/CopyingAMIs.html

Amazon API Gateway is a fully managed service that makes it easy for developers to create, publish, maintain, monitor, and secure APIs at any scale. With a few clicks in the AWS Management Console, you can create an API that acts as a “front door” for applications to access data, business logic, or functionality from your back-end services, such as workloads running on Amazon Elastic Compute Cloud (Amazon EC2), code running on AWS Lambda, or any web application. Since it can use AWS Lambda, you can run your APIs without servers.

Amazon API Gateway handles all the tasks involved in accepting and processing up to hundreds of thousands of concurrent API calls, including traffic management, authorization and access control, monitoring, and API version management. Amazon API Gateway has no minimum fees or startup costs. You pay only for the API calls you receive and the amount of data transferred out.

Reference:

https://aws.amazon.com/api-gateway/

Check out this Amazon API Gateway Cheat Sheet:

https://tutorialsdojo.com/aws-cheat-sheet-amazon-api-gateway/

Take note that CloudHSM provides a secure key storage in tamper-resistant hardware available in multiple Availability Zones (AZs) and not just on one AZ. Hence, Option 4 is the incorrect answer.

AWS CloudHSM runs in your own Amazon Virtual Private Cloud (VPC), enabling you to easily use your HSMs with applications running on your Amazon EC2 instances. With CloudHSM, you can use standard VPC security controls to manage access to your HSMs.

Your applications connect to your HSMs using mutually authenticated SSL channels established by your HSM client software. Since your HSMs are located in Amazon datacenters near your EC2 instances, you can reduce the network latency between your applications and HSMs versus an on-premises HSM.

• AWS manages the hardware security module (HSM) appliance but does not have access to your keys
• You control and manage your own keys
• Application performance improves (due to close proximity with AWS workloads)
• Secure key storage in tamper-resistant hardware available in multiple Availability Zones (AZs)
• Your HSMs are in your Virtual Private Cloud (VPC) and isolated from other AWS networks.

Separation of duties and role-based access control is inherent in the design of the AWS CloudHSM. AWS monitors the health and network availability of your HSMs but is not involved in the creation and management of the key material stored within your HSMs. You control the HSMs and the generation and use of your encryption keys.

Reference:

https://aws.amazon.com/cloudhsm/

Since you need to connect to your EC2 instance via the Internet, you basically need to ensure that your VPC has an attached Internet Gateway so it can communicate with the outside world. Your instance should also have either public IP or Elastic IP address. In this scenario, you don't need a Secondary Private IP Address since it is only used inside your VPC.

To enable access to or from the internet for instances in a VPC subnet, you must do the following:

References:

https://aws.amazon.com/premiumsupport/knowledge-center/secondary-private-ip-address/

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html/

Check out this Amazon EC2 Cheat Sheet:

https://tutorialsdojo.com/aws-cheat-sheet-amazon-elastic-compute-cloud-amazon-ec2/

Amazon Athena is an interactive query service that makes it easy to analyze data directly in Amazon Simple Storage Service (Amazon S3) using standard SQL. With a few actions in the AWS Management Console, you can point Athena at your data stored in Amazon S3 and begin using standard SQL to run ad-hoc queries and get results in seconds.

Athena is serverless, so there is no infrastructure to set up or manage, and you pay only for the queries you run. Athena scales automatically—executing queries in parallel—so results are fast, even with large datasets and complex queries.

Athena helps you analyze unstructured, semi-structured, and structured data stored in Amazon S3. Examples include CSV, JSON, or columnar data formats such as Apache Parquet and Apache ORC. You can use Athena to run ad-hoc queries using ANSI SQL, without the need to aggregate or load the data into Athena.

Hence, the most cost-effective and appropriate answer in this scenario is Option 3: Using AWS Athena. 

Options 1, 2 and 4 are all incorrect because it is not necessary to set up a database to be able to analyze the CSV export file. You can use a cost-effective option (AWS Athena), which is a serverless service that enables you to pay only for the queries you run. 

Reference: 

https://docs.aws.amazon.com/athena/latest/ug/what-is.html

Check out this Amazon Athena Cheat Sheet:

https://tutorialsdojo.com/aws-cheat-sheet-amazon-athena/

Failover is automatically handled by Amazon Aurora so that your applications can resume database operations as quickly as possible without manual administrative intervention.

If you have an Amazon Aurora Replica in the same or a different Availability Zone, when failing over, Amazon Aurora flips the canonical name record (CNAME) for your DB Instance to point at the healthy replica, which in turn is promoted to become the new primary. Start-to-finish, failover typically completes within 30 seconds.

If you do not have an Amazon Aurora Replica (i.e. single instance), Aurora will first attempt to create a new DB Instance in the same Availability Zone as the original instance. If unable to do so, Aurora will attempt to create a new DB Instance in a different Availability Zone. From start to finish, failover typically completes in under 15 minutes.

Hence, the correct answer is Option 2.

Options 1 and 3 are incorrect because this will only happen if you are using an Amazon Aurora Replica. In addition, Amazon Aurora flips the canonical name record (CNAME) and not the A record (IP address) of the instance.

Option 4 is incorrect because Aurora will first attempt to create a new DB Instance in the same Availability Zone as the original instance. If unable to do so, Aurora will attempt to create a new DB Instance in a different Availability Zone and not the other way around.

Reference:

https://aws.amazon.com/rds/aurora/faqs/

Check out this Amazon Aurora Cheat Sheet:

https://tutorialsdojo.com/aws-cheat-sheet-amazon-aurora/

In Auto Scaling, the following statements are correct regarding the cooldown period:

1. It ensures that the Auto Scaling group does not launch or terminate additional EC2 instances before the previous scaling activity takes effect.
2. Its default value is 300 seconds.
3. It is a configurable setting for your Auto Scaling group.

Options 1, 2, and 5 are incorrect as these statements are false in depicting what the word "cooldown" actually means for Auto Scaling. The cooldown period is a configurable setting for your Auto Scaling group that helps to ensure that it doesn't launch or terminate additional instances before the previous scaling activity takes effect. After the Auto Scaling group dynamically scales using a simple scaling policy, it waits for the cooldown period to complete before resuming scaling activities.

The figure below demonstrates the scaling cooldown:

Reference: 

http://docs.aws.amazon.com/autoscaling/latest/userguide/as-instance-termination.html

Check out this AWS Auto Scaling Cheat Sheet:

https://tutorialsdojo.com/aws-cheat-sheet-aws-auto-scaling/

Security and Compliance is a shared responsibility between AWS and the customer. This shared model can help relieve customer’s operational burden as AWS operates, manages and controls the components from the host operating system and virtualization layer down to the physical security of the facilities in which the service operates. The customer assumes responsibility and management of the guest operating system (including updates and security patches), other associated application software as well as the configuration of the AWS provided security group firewall.

Customers should carefully consider the services they choose as their responsibilities vary depending on the services used, the integration of those services into their IT environment, and applicable laws and regulations. The nature of this shared responsibility also provides the flexibility and customer control that permits the deployment. This differentiation of responsibility is commonly referred to as Security “of” the Cloud versus Security “in” the Cloud.

The shared responsibility model for infrastructure services, such as Amazon Elastic Compute Cloud (Amazon EC2) for example, specifies that AWS manages the security of the following assets:

• -Facilities
• -Physical security of hardware
• -Network infrastructure
• -Virtualization infrastructure 

You as the customer are responsible for the security of the following assets:

• -Amazon Machine Images (AMIs)
• -Operating systems
• -Applications
• -Data in transit
• -Data at rest
• -Data stores
• -Credentials
• -Policies and configuration

For a better understanding about this topic, refer to the AWS Security Best Practices whitepaper on the reference link below and also the Shared Responsibility Model diagram:

References: 

https://d0.awsstatic.com/whitepapers/aws-security-best-practices.pdf

https://aws.amazon.com/compliance/shared-responsibility-model/

The virtual devices for instance store volumes are named as ephemeral[0-23]. Instance types that support one instance store volume have ephemeral0. Instance types that support two instance store volumes have ephemeral0 and ephemeral1, and so on until ephemeral23 

The data in an instance store persists only during the lifetime of its associated instance. If an instance reboots (intentionally or unintentionally), data in the instance store persists. However, data in the instance store is lost under the following circumstances:

• -The underlying disk drive fails
• -The instance stops
• -The instance terminates

The word ephemeral means short-lived or temporary in the English dictionary. Hence, when you see this word in AWS, always consider this as just a temporary memory or a short-lived storage. 

Reference: 

http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/InstanceStorage.html?shortFooter=true#instance-store-lifetime

Check out this Amazon EC2 Cheat Sheet:

https://tutorialsdojo.com/aws-cheat-sheet-amazon-elastic-compute-cloud-amazon-ec2/

References:

https://aws.amazon.com/public-datasets/

There is no additional charge for AWS CloudFormation. You only pay for the AWS resources that are created (e.g. Amazon EC2 instances, Elastic Load Balancing load balancers, etc.)

Reference:

https://aws.amazon.com/cloudformation/faqs/

Check out this AWS CloudFormation Cheat Sheet:

https://tutorialsdojo.com/aws-cheat-sheet-aws-cloudformation/

When you create or modify your DB instance to run as a Multi-AZ deployment, Amazon RDS automatically provisions and maintains a synchronous standby replica in a different Availability Zone. Updates to your DB Instance are synchronously replicated across Availability Zones to the standby in order to keep both in sync and protect your latest database updates against DB instance failure. 

Option 2 is incorrect as a Read Replica provides an asynchronous replication instead of synchronous. In addition, a Read Replica is only available in Aurora, MySQL, MariaDB, and PostgreSQL database engines. 

Options 3 and 4 are wrong answers as both DynamoDB and CloudFront do not have a Read Replica feature.

Reference:

https://aws.amazon.com/rds/details/multi-az/

Check out this Amazon RDS Cheat Sheet:

https://tutorialsdojo.com/aws-cheat-sheet-amazon-relational-database-service-amazon-rds/

In Amazon Redshift, you use workload management (WLM) to define the number of query queues that are available, and how queries are routed to those queues for processing. WLM is part of parameter group configuration. A cluster uses the WLM configuration that is specified in its associated parameter group.

When you create a parameter group, the default WLM configuration contains one queue that can run up to five queries concurrently. You can add additional queues and configure WLM properties in each of them if you want more control over query processing. Each queue that you add has the same default WLM configuration until you configure its properties. When you add additional queues, the last queue in the configuration is the default queue. Unless a query is routed to another queue based on criteria in the WLM configuration, it is processed by the default queue. You cannot specify user groups or query groups for the default queue.

As with other parameters, you cannot modify the WLM configuration in the default parameter group. Clusters associated with the default parameter group always use the default WLM configuration. If you want to modify the WLM configuration, you must create a parameter group and then associate that parameter group with any clusters that require your custom WLM configuration.

Reference:

https://docs.aws.amazon.com/redshift/latest/mgmt/workload-mgmt-config.html

Check out this Amazon Redshift Cheat Sheet:

https://tutorialsdojo.com/aws-cheat-sheet-amazon-redshift/

In Amazon S3, all objects by default are private. Only the object owner has permission to access these objects. However, the object owner can optionally share objects with others by creating a pre-signed URL, using their own security credentials, to grant time-limited permission to download the objects.

When you create a pre-signed URL for your object, you must provide your security credentials, specify a bucket name, an object key, specify the HTTP method (GET to download the object) and expiration date and time. The pre-signed URLs are valid only for the specified duration.

Anyone who receives the pre-signed URL can then access the object. For example, if you have a video in your bucket and both the bucket and the object are private, you can share the video with others by generating a pre-signed URL.

Reference: 

https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-signed-urls.html

Check out this Amazon CloudFront Cheat Sheet:

https://tutorialsdojo.com/aws-cheat-sheet-amazon-cloudfront/

By using Versioning and enabling MFA (Multi-Factor Authentication) Delete, you can secure and recover your S3 objects from accidental deletion or overwrite. 

Versioning is a means of keeping multiple variants of an object in the same bucket. Versioning-enabled buckets enable you to recover objects from accidental deletion or overwrite. You can use versioning to preserve, retrieve, and restore every version of every object stored in your Amazon S3 bucket. With versioning, you can easily recover from both unintended user actions and application failures.

You can also optionally add another layer of security by configuring a bucket to enable MFA (Multi-Factor Authentication) Delete, which requires additional authentication for either of the following operations:

• Change the versioning state of your bucket
• Permanently delete an object version

MFA Delete requires two forms of authentication together:

• Your security credentials
• The concatenation of a valid serial number, a space, and the six-digit code displayed on an approved authentication device

Reference: 

https://docs.aws.amazon.com/AmazonS3/latest/dev/Versioning.html

Check out this Amazon S3 Cheat Sheet:

https://tutorialsdojo.com/aws-cheat-sheet-amazon-s3/

The question refers to one of the common scenarios for temporary credentials in AWS. Temporary credentials are useful in scenarios that involve identity federation, delegation, cross-account access, and IAM roles. In this example, it is called enterprise identity federation considering that you also need to set up a single sign-on (SSO) capability.

The correct answers are:

• -Setup a Federation proxy or an Identity provider
• -Setup an AWS Security Token Service to generate temporary tokens
• -Configure an IAM role 

In an enterprise identity federation, you can authenticate users in your organization's network, and then provide those users access to AWS without creating new AWS identities for them and requiring them to sign in with a separate user name and password. This is known as the single sign-on (SSO) approach to temporary access. AWS STS supports open standards like Security Assertion Markup Language (SAML) 2.0, with which you can use Microsoft AD FS to leverage your Microsoft Active Directory. You can also use SAML 2.0 to manage your own solution for federating user identities.

Reference:

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_saml.html

Check out this AWS IAM Cheat Sheet: 

https://tutorialsdojo.com/aws-cheat-sheet-aws-identity-and-access-management-iam/

The main issue here is that the order management system produces duplicate orders at times. Since the company is using SQS, there is a possibility that a message can have a duplicate in case an EC2 instance failed to delete the already processed message. To prevent this issue from happening, you have to use Amazon Simple Workflow service instead of SQS.

For standard queues, the visibility timeout isn't a guarantee against receiving a message twice. Hence, Option 2 is incorrect. To avoid duplicate SQS messages, it is better to design your applications to be idempotent (they should not be affected adversely when processing the same message more than once).

Amazon SWF helps developers build, run, and scale background jobs that have parallel or sequential steps. You can think of Amazon SWF as a fully-managed state tracker and task coordinator in the Cloud. If your app's steps take more than 500 milliseconds to complete, you need to track the state of processing, and you need to recover or retry if a task fails.

References: 

https://aws.amazon.com/swf/

https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-visibility-timeout.html

Check out this Amazon SQS Cheat Sheet:

https://tutorialsdojo.com/aws-cheat-sheet-amazon-sqs/

Changes made in a Security Group is immediately implemented to all associated EC2 instances.

A security group acts as a virtual firewall for your instance to control inbound and outbound traffic. When you launch an instance in a VPC, you can assign up to five security groups to the instance. Security groups act at the instance level, not the subnet level. Therefore, each instance in a subnet in your VPC could be assigned to a different set of security groups. If you don't specify a particular group at launch time, the instance is automatically assigned to the default security group for the VPC.

References:

http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_SecurityGroups.html

Since the web portal consists of both web and database servers, it is best to launch the web servers into the public subnet and the database server into the private subnet. Hence, Option 2 is the right answer.

Although you can use a single public subnet for your web and database servers, it will be a massive security risk as you are exposing your database publicly to the Internet.

Reference:

http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Scenario2.html 

Check out this Amazon VPC Cheat Sheet:

https://tutorialsdojo.com/aws-cheat-sheet-amazon-vpc/

AWS provides a set of fully managed services such as Lambda, API Gateway, DynamoDB, and many others that you can use to build and run serverless applications. Serverless applications don't require provisioning, maintaining, and administering servers for backend components such as compute, databases, storage, stream processing, message queueing, and more.

You also no longer need to worry about ensuring application fault tolerance and availability. Instead, AWS handles all of these capabilities for you. This allows you to focus on product innovation while enjoying faster time-to-market.

Option 3 is incorrect since ECS is a container orchestration service that supports Docker containers for you to run containerized services. It is not serverless since you will still be managing the docker containers yourself.

Option 4 is incorrect since EC2 is not serverless, even if you purchased reserved instances of them.

Option 5 is incorrect since SWF is a state tracker and task coordinator in the Cloud.

Reference:

https://aws.amazon.com/serverless/

Check out these AWS Lambda, Amazon DynamoDB and API Gateway Cheat Sheets:

https://tutorialsdojo.com/aws-cheat-sheet-aws-lambda/

https://tutorialsdojo.com/aws-cheat-sheet-amazon-dynamodb/

https://tutorialsdojo.com/aws-cheat-sheet-amazon-api-gateway/

Here is an in-depth tutorial on serverless applications:

Amazon Snowball is a petabyte-scale data transport solution that uses secure appliances to transfer large amounts of data into and out of the AWS cloud. Using Snowball addresses common challenges with large-scale data transfers including high network costs, long transfer times, and security concerns. Transferring data with Snowball is simple, fast, secure, and can be as little as one-fifth the cost of high-speed Internet.

Reference:

https://aws.amazon.com/snowball/

Check out this AWS Snowball Cheat Sheet:

https://tutorialsdojo.com/aws-cheat-sheet-aws-snowball/ 

Instance metadata is the data about your instance that you can use to configure or manage the running instance. You can get the instance ID, public keys, public IP address and many other information from the instance metadata by firing a URL command in your instance to this URL:

http://169.254.169.254/latest/meta-data/

Option 1 is incorrect because the instance user data is mainly used to perform common automated configuration tasks and run scripts after the instance starts.

Option 2 is incorrect because resource tags are labels that you assign to an AWS resource. Each tag consists of a key and an optional value, both of which you define.

Option 4 is incorrect because Amazon Machine Image (AMI) mainly provides the information required to launch an instance, which is a virtual server in the cloud.

Reference:

http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.htm

Check out this Amazon EC2 Cheat Sheet:

https://tutorialsdojo.com/aws-cheat-sheet-amazon-elastic-compute-cloud-amazon-ec2/

Amazon S3 offers a highly durable, scalable, and secure destination for backing up and archiving your critical data. This is the correct option as the start-up company is looking for a durable storage to store the audio and text files.

• Option 1 is incorrect as AmazonRedshift is usually used as a Data Warehouse.
• Option 2 is incorrect as Amazon Glacier is usually used for data archives.
• Option 4 is incorrect as data stored in an instance store is not durable.

References:

https://aws.amazon.com/s3/

In this scenario, the best option is to use Amazon S3. It’s a simple storage service that offers a highly-scalable, reliable, and low-latency data storage infrastructure at very low costs.

Options 1 and 4 are incorrect because these services do not provide durable storage.

Option 2 is incorrect because Amazon Glacier is mainly used for data archives with data retrieval times that can take some few hours. Hence, it is not suitable for the transcription service where the data are stored and frequently accessed.

Reference:

https://aws.amazon.com/s3/faqs/

Check out this Amazon S3 Cheat Sheet:

https://tutorialsdojo.com/aws-cheat-sheet-amazon-s3/

The first step is to create a snapshot of the EBS volume. Create a volume using this snapshot and then specify the new Availability Zone accordingly.

A point-in-time snapshot of an EBS volume, can be used as a baseline for new volumes or for data backup. If you make periodic snapshots of a volume, the snapshots are incremental—only the blocks on the device that have changed after your last snapshot are saved in the new snapshot. Even though snapshots are saved incrementally, the snapshot deletion process is designed so that you need to retain only the most recent snapshot in order to restore the entire volume.

Snapshots occur asynchronously; the point-in-time snapshot is created immediately, but the status of the snapshot is pending until the snapshot is complete (when all of the modified blocks have been transferred to Amazon S3), which can take several hours for large initial snapshots or subsequent snapshots where many blocks have changed. While it is completing, an in-progress snapshot is not affected by ongoing reads and writes to the volume.

References:

http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSSnapshots.html

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-restoring-volume.html

Check out this Amazon EBS Cheat Sheet:

https://tutorialsdojo.com/aws-cheat-sheet-amazon-ebs/

Considering that the company is using a corporate Active Directory, it is best to use AWS Directory Service AD Connector for easier integration. In addition, since the roles are already assigned using groups in the corporate Active Directory, it would be better to also use IAM Roles. Take note that you can assign an IAM Role to the users or groups from your Active Directory once it is integrated with your VPC via the AWS Directory Service AD Connector.

AWS Directory Service provides multiple ways to use Amazon Cloud Directory and Microsoft Active Directory (AD) with other AWS services. Directories store information about users, groups, and devices, and administrators use them to manage access to information and resources. AWS Directory Service provides multiple directory choices for customers who want to use existing Microsoft AD or Lightweight Directory Access Protocol (LDAP)–aware applications in the cloud. It also offers those same choices to developers who need a directory to manage users, groups, devices, and access.

Reference: 

https://aws.amazon.com/blogs/security/how-to-connect-your-on-premises-active-directory-to-aws-using-ad-connector/

Check out this AWS IAM Cheat Sheet:

https://tutorialsdojo.com/aws-cheat-sheet-aws-identity-and-access-management-iam/

Here is a video tutorial on AWS Directory Service:

Reference:

https://aws.amazon.com/sns/faqs/

Check out this Amazon SNS Cheat Sheet:

https://tutorialsdojo.com/aws-cheat-sheet-amazon-sns/

You can choose the credentials that are right for your IAM user. When you use the AWS Management Console to create a user, you must choose to at least include a console password or access keys. By default, a brand new IAM user created using the AWS CLI or AWS API has no credentials of any kind. You must create the type of credentials for an IAM user based on the needs of your user.

Access keys are long-term credentials for an IAM user or the AWS account root user. You can use access keys to sign programmatic requests to the AWS CLI or AWS API (directly or using the AWS SDK). Users need their own access keys to make programmatic calls to AWS from the AWS Command Line Interface (AWS CLI), Tools for Windows PowerShell, the AWS SDKs, or direct HTTP calls using the APIs for individual AWS services.

To fill this need, you can create, modify, view, or rotate access keys (access key IDs and secret access keys) for IAM users. When you create an access key, IAM returns the access key ID and secret access key. You should save these in a secure location and give them to the user.

Option 1 is incorrect because by default, a brand new IAM user created using the AWS CLI or AWS API has no credentials of any kind. Take note that in the scenario, you created the new IAM user using the AWS CLI and not via the AWS Management Console, where you must choose to at least include a console password or access keys when creating a new IAM user.

Option 2 is incorrect because enabling Multi-Factor Authentication for the IAM user will still not provide the required Access Keys needed to send API calls to your AWS resources. You have to grant the IAM user with Access Keys to meet the requirement.

Option 3 is incorrect because adding a new IAM policy to the new user will not grant the needed Access Keys needed to make API calls to the AWS resources.

References:

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html#id_users_creds 

Check out this AWS IAM Cheat Sheet:

https://tutorialsdojo.com/aws-cheat-sheet-aws-identity-and-access-management-iam/

Amazon S3 Standard - Infrequent Access (Standard - IA) is an Amazon S3 storage class for data that is accessed less frequently, but requires rapid access when needed. Standard - IA offers the high durability, throughput, and low latency of Amazon S3 Standard, with a low per GB storage price and per GB retrieval fee.

This combination of low cost and high performance make Standard - IA ideal for long-term storage, backups, and as a data store for disaster recovery. The Standard - IA storage class is set at the object level and can exist in the same bucket as Standard, allowing you to use lifecycle policies to automatically transition objects between storage classes without any application changes.

Key Features:

• -Same low latency and high throughput performance of Standard
• -Designed for durability of 99.999999999% of objects
• -Designed for 99.9% availability over a given year
• -Backed with the Amazon S3 Service Level Agreement for availability
• -Supports SSL encryption of data in transit and at rest
• -Lifecycle management for automatic migration of objects

The option: "It provides high latency and low throughput performance" is wrong as it should be "low latency" and "high throughput" instead.

The option: "It is the best storage option to store noncritical and reproducible data" is wrong as it actually refers to Amazon S3 - Reduced Redundancy Storage (RRS). 

The option: "Ideal to use for data archiving." is wrong because this statement refers to Amazon Glacier.

Reference:

https://aws.amazon.com/s3/storage-classes/

Check out this Amazon S3 Cheat Sheet:

https://tutorialsdojo.com/aws-cheat-sheet-amazon-s3/

The correct answers are options 1 & 4:

• Increased database availability in the case of system upgrades like OS patching or DB Instance scaling.
• It makes the database fault-tolerant to an Availability Zone failure

Option 3 is almost correct. RDS synchronously replicates the data to a standby instance in a different Availability Zone (AZ) that is in the same region and not in a different one.

Options 2 and 5 are incorrect as it does not affect the performance nor provide SQL optimization.

Amazon RDS Multi-AZ deployments provide enhanced availability and durability for Database (DB) Instances, making them a natural fit for production database workloads. When you provision a Multi-AZ DB Instance, Amazon RDS automatically creates a primary DB Instance and synchronously replicates the data to a standby instance in a different Availability Zone (AZ). Each AZ runs on its own physically distinct, independent infrastructure, and is engineered to be highly reliable.

In case of an infrastructure failure, Amazon RDS performs an automatic failover to the standby (or to a read replica in the case of Amazon Aurora), so that you can resume database operations as soon as the failover is complete. Since the endpoint for your DB Instance remains the same after a failover, your application can resume database operation without the need for manual administrative intervention.

Reference:

https://aws.amazon.com/rds/details/multi-az/

Check out this Amazon RDS Cheat Sheet:

https://tutorialsdojo.com/aws-cheat-sheet-amazon-relational-database-service-amazon-rds/

Reference:

https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Scenario2.html

Check out this Amazon VPC Cheat Sheet:

https://tutorialsdojo.com/aws-cheat-sheet-amazon-vpc/

To avoid accidental deletion in Amazon S3 bucket, you can:

• -Enable Versioning
• -Enable MFA (Multi-Factor Authentication) Delete

Versioning is a means of keeping multiple variants of an object in the same bucket. You can use versioning to preserve, retrieve, and restore every version of every object stored in your Amazon S3 bucket. With versioning, you can easily recover from both unintended user actions and application failures.

If the MFA (Multi-Factor Authentication) Delete is enabled, it requires additional authentication for either of the following operations.

• -Change the versioning state of your bucket
• -Permanently delete an object version

Reference:

http://docs.aws.amazon.com/AmazonS3/latest/dev/Versioning.html

Check out this Amazon S3 Cheat Sheet:

https://tutorialsdojo.com/aws-cheat-sheet-amazon-s3/

All data transferred between any type of gateway appliance and AWS storage is encrypted using SSL. By default, all data stored by AWS Storage Gateway in S3 is encrypted server-side with Amazon S3-Managed Encryption Keys (SSE-S3). Also, when using the file gateway, you can optionally configure each file share to have your objects encrypted with AWS KMS-Managed Keys using SSE-KMS.

Data stored in Amazon Glacier is protected by default; only vault owners have access to the Amazon Glacier resources they create. Amazon Glacier encrypts your data at rest by default and supports secure data transit with SSL.

References:

https://aws.amazon.com/storagegateway/faqs/ 

https://aws.amazon.com/glacier/features

Amazon Simple Queue Service (SQS) is a fully managed message queuing service that makes it easy to decouple and scale microservices, distributed systems, and serverless applications. Building applications from individual components that each perform a discrete function improves scalability and reliability, and is best practice design for modern applications. SQS makes it simple and cost-effective to decouple and coordinate the components of a cloud application. Using SQS, you can send, store, and receive messages between software components at any volume, without losing messages or requiring other services to be always available.

Reference:

https://aws.amazon.com/sqs/ 

Check out this Amazon SQS Cheat Sheet:

https://tutorialsdojo.com/aws-cheat-sheet-amazon-sqs/

https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-sticky-sessions.html 

Check out this AWS Elastic Load Balancing (ELB) Cheat Sheet:

https://tutorialsdojo.com/aws-cheat-sheet-aws-elastic-load-balancing-elb/

http://169.254.169.254/latest/meta-data/ is the URL that you can use to retrieve the Instance Metadata of your EC2 instance, including the public-hostname, public-ipv4, public-keys et cetera.

This can be helpful when you're writing scripts to run from your instance as it enables you to access the local IP address of your instance from the instance metadata to manage a connection to an external application. Remember that you are not billed for HTTP requests used to retrieve instance metadata and user data.

Reference:

http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html

Check out this Amazon EC2 Cheat Sheet:

https://tutorialsdojo.com/aws-cheat-sheet-amazon-elastic-compute-cloud-amazon-ec2/

Using Redis AUTH command can improve data security by requiring the user to enter a password before they are granted permission to execute Redis commands on a password-protected Redis server. Hence, Option 3 is the correct answer.

To require that users enter a password on a password-protected Redis server, include the parameter --auth-token with the correct password when you create your replication group or cluster and on all subsequent commands to the replication group or cluster.

Option 1 is incorrect because this is not possible in IAM. You have to use the Redis AUTH option instead.

Option 2 is incorrect because the Redis At-Rest Encryption feature only secures the data inside the in-memory data store. You have to use Redis AUTH option instead.

Option 4 is incorrect because although in-transit encryption is part of the solution, it is missing the most important thing which is the Redis AUTH option.

References:

https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/auth.html

https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/encryption.html

Check out this Amazon Elasticache cheat sheet:

https://tutorialsdojo.com/aws-cheat-sheet-amazon-elasticache/

Vertical scaling means running the same software on bigger machines which is limited by the capacity of the individual server. Horizontal scaling is adding more servers to the existing pool and doesn’t run into limitations of individual servers.

Fine-grained decoupling of microservices is a best practice for building large-scale systems. It’s a prerequisite for performance optimization since it allows choosing the appropriate and optimal technologies for a specific service. Each service can be implemented with the appropriate programming languages and frameworks, leverage the optimal data persistence solution, and be fine-tuned with the best performing service configurations.

Properly decoupled services can be scaled horizontally and independently from each other. Vertical scaling, which is running the same software on bigger machines, is limited by the capacity of individual servers and can incur downtime during the scaling process. Horizontal scaling, which is adding more servers to the existing pool, is highly dynamic and doesn’t run into limitations of individual servers. The scaling process can be completely automated.

Furthermore, the resiliency of the application can be improved because failing components can be easily and automatically replaced. Hence, Option 3 is the correct answer.

Option 1 is incorrect because Vertical scaling is not about running the same software on a fully serverless architecture. AWS Lambda is not required for scaling.

Option 2 is incorrect because the definitions for the two concepts were switched. Vertical scaling means running the same software on bigger machines which is limited by the capacity of the individual server. Horizontal scaling is adding more servers to the existing pool and doesn’t run into limitations of individual servers.

Option 4 is incorrect because Horizontal scaling is not related to using ECS or EKS containers on a smaller instance.

Reference:

https://docs.aws.amazon.com/aws-technical-content/latest/microservices-on-aws/microservices-on-aws.pdf#page=8